Change handling of renames #1549
Conversation
|
Closes #1546 |
|
I'll be honest in that I don't really have a great handle on what's going on here, but this all looks largely like innocuous changes passing more parameters around and/or fallout from tweaking interfaces. In that sense the guts of the patch look good to me and I think we can probably go ahead and land. I think there's some test failures on CI though? Otherwise r=me. As one other thought, though, this is trying to use the "from" name in the renames to display names, right? Shouldn't it use the "to" names eventually? I think with this patch we'd start saying |
We'll need more rustup changes once we want to switch again. We might just live with 'from' and 'to' being the wrong way around forever. But I don't think we can change this backwards compatibly. |
|
Mk, I'm fine landing this! |
This PR makes handling of renamed components more flexible by allowing components to be added or removed based on either the 'before' or 'after' names. We always use the 'before' name when communicating with the user, but use the 'after' name internally (basically just in the manifest).
This is a backwards-compatible stop-gap. It means that for the edition we can talk about 'rls' rather than 'rls-preview'. (Assuming renames are from 'rls' to 'rls-preview', which is the current situation in the manifest).
The final commit adds an instruction for adding missing components to rustup's proxies.
Since Rustup is not distributed with Rust, this does not need to be part of the edition, timing-wise. However, it would be good to have this in the wild and tested somewhat so that new users will get the benefits when the edition is released.
r? @alexcrichton